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i nteroff i ce 
memorandum 



To: Architecture Committee List 

CC: Dave Braithwaite 
Ulf Fagerquist 
Peter Hurley 
Vern Poulter 
Jack Rosen 



Date: 


28 Mar 83 


From: 


Hike Uhler 


Dept: 


L.S.E.G. 


DTN: 


(8-) 231-6448 



Loc/Mail stop: MR01-2/E85 
Net mail: UHLER at 10 



Subject: Functional ciianges to the PDP-10 architecture 



During the past few years, we have been rather lax in clearly 
documenting changes to the PDP-10 architecture. In some 
instances, this was due to the lack of acceptable minutes taken at 
Architecture Committee meetings. In others, we made changes to 
the architecture based on ambiguous or incomplete specifications. 
There are probably other reasons and we can debate them endlessly. 

We are about to begin the hardware design phase of the Jupiter II 
CPU which has aggressive performance goals. In order to meet both 
the performance goals and the requirement that the design be 
functionally correct, we must reevaluate our policy on making 
changes to the architecture if such changes are to be included in 
the Jupiter II design. 

The initial functional description of the machine will be taken 
from the following sources: 

o Processor Reference Manual (AA-H391A-TK with June 1982 update 
AD-H391A-T1 installed) . 

o KCIO version 8 (March 29, I983) • 

My memo on Extended Addressing has been included as a chapter in 
KCIO and the description of extended addressing described in that 
chapter is part of the functional description of the machine. 

Other requests for functional changes or corrections to the listed 
documentation which you wish to have included in the Jupiter II 
implementation of the architecture must be received by me no later 
than 17:00, Friday, 29-Apr-83. To be considered, a proposed 
change must have been reviewed and approved at a meeting of the 
PDP-10 Architecture Committee. In addition, a complete functional 
specification of the proposed change, including normal and 
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exception handling must be included. To avoid later problems of 
second-guessing why a change was made, I suggest that the change 
also include minutes of the discussion of the change. 

As In the past, we will consider adding changes received after 
tliis date to the machine on a case-by-case basis. 

It should be pointed out that some performance goals will probably 
require extensive hardware support. Because hardware is more 
difficult to change than microcode, the cost of making repeated 
changes to the architecture later on may be quite high. 



